Recently, there has been an explosive growth of the Internet. This is coupled with the increasing popularity of notebook type computers. The Internet allows users to access huge databases of information. It also provides users with powerful communication tools like e-mail. Furthermore, notebook computers give users the ability to access the Internet anywhere. Consequently, more and more notebook users would like to access the Internet while moving.
Initially, the Internet Protocol (IP) did not contain mobility protocols. As a result, if a mobile host moves without changing its address, it will not be reachable (i.e., packets sent to the mobile host will not be routed correctly. On the other hand, if the mobile host changes its address, it will lose its connections made with the previous address.
Host mobility is not a new concept. Already, there are years of research in this area resulting in several proposals. In 1996, the Internet Engineering Task Force (IETF) has proposed Mobile IP RFC2002 which allows computers to roam freely to other networks while still maintaining the same IP address. Mobile IP is a means for providing location independent routing support to a mobile node by allowing the mobile node to keep the same IP address while changing location. This operation is transparent to the mobile's user. It is intended to enable nodes to move from one IP sub-net to another. Its principle is simple: Mobile IP does not use any physical layers nor does it assume a particular type of physical layer. Therefore, it can operate using many different types of physical layers.
Several special entities have been defined in the Mobile IP architecture proposed by the IETF. The home agent (HA) and the foreign agent (FA) work together to allow a user's mobile node (MN) (or mobile host (MH)) to move freely around the Internet without changing its IP address. Each network that wants to allow its users to roam to another network has a home agent. Every site that wishes to allow visitors has a foreign agent. Any router on a network can serve as a home agent, foreign agent or both. In addition, a user who wants to send packets to the mobile host is called a correspondent node (CN).
When a MN is connected to a foreign network, it uses agent discovery messages to locate a foreign agent that is willing to provide mobility support to the MN while attached to the foreign network. Once a FA is discovered, the MN registers using the registration messages and sends its registration request to the FA. Then, the FA forwards the registration message to the user's home agent, which includes a care-of address, which is typically the foreign agent's IP address. (A care-of address is an IP address allocated to the mobile node's current point of attachment to the Internet if the mobile node is not attached to its home domain).
The HA captures all datagrams sent by correspondent nodes to the MN and encapsulates each datagram sent to the mobile host using the care-of address of the mobile node as a destination of the new datagram. This allows the HA to route the datagrams toward the new FA using a tunnel. The FA decapsulates the incoming datagrams and forwards the original information toward the MN.
Mobile IP (as it was created in 1996) is currently not equipped to handle users moving frequently through large areas with their mobile device connected. Furthermore, the number of MN's requesting roaming in new sub-networks is increasing. For example, people working with their connected PDA while traveling on a bus or a train change sub-networks quiet often. Consequently, the Mobile IP protocol is facing the following problems:                The mobile may or may not keep on receiving the previous packets coming from the previous sub-network while moving toward a new sub-network, i.e., performing a handoff at the mobile IP level. It depends on the physical layer implementation of radio technologies that is currently being used by the mobile communication system. Mobile IP does not specify usage of a specific physical layer. Thus, while activating the Mobile IP protocol to register the new location of a MN with the HA so that information can be re-routed to the new sub-network, the mobile may lose information still coming to the previous sub-network. This situation is unacceptable for applications requiring “real-time” behavior (e.g. voice over IP applications).        Mobile IP may not be a scalable solution, since the size of a routing table increases linearly with the number of mobile hosts. In addition, the frequency of updates to it is proportional to the frequency of handoffs in the system.        
One solution to these problems is to enlarge the sub-network to minimize the use of the number of registration request messages being sent to the HA by MNs. To this end, the Virtual Private Network (VPN) which creates virtual sub-networks could be used.
Several other protocols such as Seamless IP Multicast Receiver Mobility Support, Multicasting based Architecture for Internet Host Mobility, and Handoffs in Cellular Wireless Networks: the daedalus implementation have been proposed to address these problems. An overview of the design of these protocols is given below.
Seamless IP Multicast Receiver Mobility Support
Introduction
This licentiate proposal “Seamless IP Multicast Receiver Mobility Support” specifies a mobility support agent (MSA) protocol which provides a mechanism to help ensure seamless reception of IP multicast traffic despite a mobile node's handoff. This is possible because in advance of its handoff, a mobile node pre-registers with the MSA agent on the next network to be visited. Unlike the present invention, “Seamless IP Multicast Receiver Mobility Support” is not intended to enhance the Mobile IP protocol, but to be used in parallel with it. Furthermore, it would perform a handoff in the unique case of a mobile host already receiving multicast traffic.
Terminology Used
The terminology used in “Seamless IP Multicast Receiver Mobility Support” is basically the same as that used in Mobile IP. Additional terminology defined in “Seamless IP Multicast Receiver Mobility Support” includes:                Visiting network:         The IP sub-net that the mobile node is currently visiting.        Neighboring network:         An IP sub-net that is geographically a neighbor of the visiting IP sub-net.        Next network (to be visited):         The IP sub-net that that the mobile node will be connected to (i.e., to which it is handed over to).        Previous network—i.e. Previously visited network:         The IP subnet that the mobile node has just visited.Principles        
When a mobile node has subscribed to a multicast session and is about to perform a handoff, there is a probability that the roaming sub-network is not yet receiving the multicast traffic. It is assumes that many multicast sessions will be sparse mode sessions, in which members are scattered over the Internet. Therefore the “latency” incurred performing a handoff is at least the time the router takes to poll an Internet Group Management Protocol (IGMP) “membership query” which is 120 seconds maximum. (See Internet Group Management Protocol, Version 2, W. Fenner, Xerox Parc, RFC 2236, November 1997). In addition, the time the mobile takes to answer with an IGMP “membership report” adds another 10 seconds maximum. Another IGMP possibility would to send an unsolicited IGMP “membership report” to avoid waiting for the IGMP polling, but this is not possible since neither the multicast applications, nor IGMP, has a mechanism to detect the mobile node handoff.
The MSA architecture introduces a new architectural entity:                Mobility Support Agent (MSA):         An agent on a network which acts as a proxy for mobile nodes to establish the multicast tree in advance of the mobile nodes' arrival. In addition, this agent can also be used to advertise the services available on its sub-network to the mobile nodes.The MSA Architecture Introduces New Control Messages:1) Agent Discovery Protocol:        
The Agent Discovery protocol is used to advertise the presence of MSAs and their services. Unlike Mobile IP [RFC2002], mobile nodes do not use MSA agent discovery protocol to determine its current location or to detect the node's movement. With the MSA architecture, movement can be detected with the help of Mobile IP or by using link layer mechanisms.
a) Inter-Agent Advertisement Message:
A group of cooperating MSAs forms their own multicast group to advertise their availability and services to each other. The address of the multicast group can either be an administrative multicast address or other pre-defined addresses.
b) Agent-MN Advertisement Protocol:
The Agent-MN advertisement makes use of the Mobile IP agent advertisement extensions of the ICMP router advertisement. Advertisement messages are transmitted by a MSA to the mobile nodes that are on the same network. The information advertised by the MSA is either directly retrieved from the Inter-agent Discovery messages, or derived from them.                i) Neighboring Network Extension2) Pre-Registration Protocol:        
a) Pre-Registration Message
In advance of performing the handoff, the mobile node pre-registers with the MSA on the next network. Based on this pre-registration the MSA, establishes the multicast tree and negotiates for services (as a proxy of the mobile node).
b) Registration Confirm Extension
The mobile node sends the confirmed registration (Registration Confirm) to the MSA only after it has moved to the next network and successfully received the first multicast datagram.
3) De-Registration Protocol:
a) De-registration message
After moving to another network, a mobile node de-registers with the MSA on the previous network. De-registration explicitly removes stale states which might otherwise lead to unnecessary traffic being sent to the previous network.
Sequence of Operations
                MSAs advertise their presence and services (bandwidth reservation, authentication, etc.) via agent advertisements. A mobile node may optionally solicit an agent advertisement from any locally attached MSAs through an agent solicitation.        A mobile node about to make a handoff chooses one or more most-likely next networks (perhaps via a movement prediction algorithm) and sends pre-registration(s) to the MSA on what are the potential next network(s).        After authentication, and following negotiation between the mobile node and each of these MSAs, these MSAs can now act as a proxy for the mobile node in setting up the requested multicast sessions. IGMP messages are exchanged between the MSA and its directly attached multicast routers.        As soon as the mobile node arrives at the next network, it resumes receiving the IP multicast traffic with minimal possible latency, since the join occurred even before it arrived.Multicasting Based Architecture for Internet Host Mobility1.1.1 Introduction        
This proposal uses IP multicasting as a mechanism to achieve mobility. Every mobile node is issued a multicast address instead of a unicast address. In addition, there is no concept of home agent/foreign agent. The multicast address is used along with location servers and multicast routers to achieve mobility. It is not a solution to the problem of micro-mobility. Instead, it is protocol that challenges Mobile IP.
Terminology
                Location Server (Distributed Directory): These are servers that store bindings between the multicast address of a MN and the multicast router (MR) serving the MN. Each MN is responsible for periodically updating its location server with information on the multicast router serving it.        Base Station (BS): In addition to the normal capabilities of the base station, in this scheme each base station also has the capability of working as a multicast router.Sequence of Operations        
When a correspondent node sends a datagram intended for a MN (having a multicast address), the multicast router serving the correspondent node (MR—CN) within the network picks up the datagram and checks a location server for information regarding the MN. The location server chosen depends upon the multicast address of the MN.
On obtaining the address of the multicast router (MR—MN) that serves the MN, the MR—CN contacts the MR—MN and joins the multicast group. In addition, it forwards the datagram. Each MR that receives the datagram, de-tunnels the datagram and forwards it to the MN. Before the MN moves from the coverage of one multicast router to another, the MN requests the MR within the new network to join the multicast group. Therefore, the MN receives an uninterrupted flow of packets when it changes coverage. As a result, both the previous MR and the new MR of the MN receives the packets for a short overlap time period.
Handoffs in Cellular Wireless Networks: the Daedalus Implementation, International Journal on Wireless Communication Systems
Introduction
Wireless data networks are usually composed of a wired, packet-switched, backbone network and one or more wireless (e.g., cellular radio or infrared) hops connecting mobile hosts to the wired part. The wireless part is organized into geographically defined cells, with a control point called a base station (BS) for each of these cells. The base stations are connected to the wired network and function as a bridge for communication between the wireless infrastructure and the Internet. As a mobile host (MH) travels between wireless cells, the task of routing data between the wired network and the MH is transferred to the new cell's base station. This process, known as a handoff, maintains end-to-end connectivity in the dynamically reconfigured network topology.
This proposal presents a handoff protocol that achieves latencies between 30 to 40 ms or less. In addition, there is no data loss in the case of handoffs between base stations that are topologically close to each other. This protocol uses both multicast for fast route updates and intelligent buffering at the base stations. However, “Handoffs in Cellular Wired Networks” is not intended to be used with Mobile IP, but to challenge it.
Terminology
The terminology used in “Handoffs in Cellular Wireless Networks” is basically the same as that used in Mobile IP. Additional terminology includes:                Mobile Host: a mobile node as defined in Mobile IP.        The Encapsulator: a software entity located in the home agent that performs the encapsulation and forwarding of IP packets destined for the mobile host to its current location.        The Route Analyzer: a software entity located in the mobile host that uses the information provided by the beacon system to configure the routes taken by packets.        The Decapsulator: A software entity located in the base station that decapsulates and either forwards packets across the wireless link to the mobile host or buffers them.Principles        
Each MH is assigned a temporary IP multicast address. The home agent encapsulates packets destined for the MH and forwards them to its associated multicast group. The members of this multicast group include the base stations in the vicinity of the mobile host, but the mobile host itself does not join the group. The BS responsible for the cell containing the MH joins the IP multicast group. At any instant of time, there is at most one primary BS in the system for a given mobile host.
In addition, in each MH an entity called the route analyzer keeps track of the recent beacons it has received to approximate its current location and motion. The MH uses statistics such as the received signal strength of the beacons and communication quality of the beacons to identify which BSs are nearby. Thus, BSs that are identified as likely handoff targets are asked to join the multicast group by the MH. These BSs do not forward the packets from the multicast group to the wireless network. Instead, they buffer the last few packets transmitted from the HA. When a MH enters such a cell, the new primary BS begins transmitting packets from its buffer of packets. This approach does not define a regional concept where handoffs are supposed to occur smoothly with fewer overheads than handoff between different regions.
1.1.2 Sequence of Operations
When a mobile host leaves its normal home location, it initializes the home agent encapsulation by specifying a predefined multicast address corresponding to it. The home agent entity called the encapsulator intercepts all packets destined for the mobile host. It encapsulates and forwards the packets to their associated multicast address.
The route analyzer for the mobile host requests one or more decapsulators in its vicinity to receive packets. Thus, the requested base stations join the IP Multicast group associated with the mobile host and receive packets intended for the mobile host. The route analyzer uses the information provided by the beacon system to choose a single base station in its area to be the current forwarding base station (the primary base station). In addition, other base stations that are likely targets for handoff listen on the mobile host's multicast group and buffer incoming packets. The mobile host itself does not join the multicast group.
The decapsulator for the primary base station decapsulates and forwards packets across the wireless link to the mobile host. The other base stations that receive packets for the mobile host do not forward them on. Instead, they buffer the last few packets received. The base station entity called the decapsulator scans all multicast packets to identify the ones that are destined for a registered mobile host. It then processes the packet based on the current state of decapsulation (either primary forwarding or nearby buffering) for the mobile host.
During the change to forwarding state, the base station forwards to the mobile host any packets that were stored while the decapsulator was in buffering mode and have not yet been delivered to the mobile host. This eliminates any loss of packets en route to the mobile during handoff. To identify which packets to transmit from the buffer, the MH passes the IP IDs of the last three packets received by it and packets after these are transmitted. Once the mobile host leaves the cell, the decapsulator returns to the buffering state. Finally, the route analyzer asks to delete the decapsulation entry from the base station and has the base station leave the associated IP Multicast group.
The protocols discussed above have some drawbacks.                The “Seamless IP Multicast Receiver Mobility Support” does not describe how the mobile node obtains the multicast address. In addition, it does not address possible conflict when two mobile nodes use the same multicast address. Furthermore, the protocol described works independently of Mobile IP [RFC2002]. This is a major drawback because Mobile IP provides a delivery mechanism for Multicast packets. On the plus side, “Seamless IP Multicast Receiver Mobility Support” enhance the efficiency of handoffs.        The “Multicasting based Architecture for Internet Host Mobility” proposal has several drawbacks. There is a limitation in the number of unique class D addresses that can be assigned to each and every MN in IPv4. Furthermore, it requires that every router in a sub-network be mobility-aware because the multicast router located near each correspondent needs to be able to find the location server to tunnel the datagram. Before a MN moves under a new coverage, it can inform the MR within that area of a possible handoff and request the MR to join the multicast group. Therefore, the MN has to know the address of the neighboring MR, and also the overhead that is involved at the MN every time it performs a handoff. Furthermore, the scalability of using a location server is something that is not very clear.        The “Handoffs in Cellular Wireless Networks: the daedalus implementation” proposal does not describes which entity in the network allocates the multicast address. Furthermore, it does not deal with the problem of simultaneous usage of the same multicast address. The proposed protocol also implies that the mobile node save the last three packets to help the base station in the decision process of which packets are to be retransmitted.        